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IPv6 Support Required for All IP-Capable Nodes 
Abstract 


Given the global lack of available IPv4 space, and limitations in 
IPv4 extension and transition technologies, this document advises 
that IPv6 support is no longer considered optional. It also cautions 
that there are places in existing IETF documents where the term "IP" 
is used in a way that could be misunderstood by implementers as the 
term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or 
IPv4-only, depending on context and application. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6540. 
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Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


IP version 4 (IPv4) has served to connect public and private hosts 
all over the world for over 30 years. However, due to the success of 
the Internet in finding new and innovative uses for IP networking, 
billions of hosts are now connected via the Internet and require 
unique addressing. This demand has led to the exhaustion of the IANA 
global pool of unique IPv4 addresses [IANA-EXHAUST], and will be 
followed by the exhaustion of the free pools for each Regional 
Internet Registry (RIR), the first of which is APNIC [APNIC-EXHAUST]. 
While transition technologies and other means to extend the lifespan 
of IPv4 do exist, nearly all of them come with trade-offs that 
prevent them from being optimal long-term solutions when compared 
with deployment of IP version 6 (IPv6) as a means to allow continued 
growth on the Internet. See [RFC6269] and [NAT444-IMPACTS] for some 
discussion on this topic. 


IPv6 [RFC1883] was proposed in 1995 as, among other things, a 
solution to the limitations on globally unique addressing that IPv4’s 
32-bit addressing space represented, and has been under continuous 
refinement (e.g., [RFC2460]) and deployment ever since. The 
exhaustion of IPv4 and the continued growth of the Internet worldwide 
have created the driver for widespread IPv6 deployment. 
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However, the IPv6é deployment necessary to reduce reliance on IPv4 has 
been hampered by a lack of ubiquitous hardware and software support 
throughout the industry. Many vendors, especially in the consumer 
space, have continued to view IPv6 support as optional. Even today, 
they are still selling "IP-capable" or "Internet-Capable" devices 
that are not IPv6-capable, which has continued to push out the point 
at which the natural hardware refresh cycle will significantly 
increase IPv6 support in the average home or enterprise network. 

They are also choosing not to update existing software to enable IPv6 
support on software-updatable devices, which is a problem because it 
is not realistic to expect that the hardware refresh cycle will 
single-handedly purge IPv4-only devices from the active network ina 
reasonable amount of time. This is a significant problem, especially 
in the consumer space, where the network operator often has no 
control over the hardware the consumer chooses to use. For the same 
reason that the average consumer is not making a purchasing decision 
based on the presence of IPv6 support in their Internet-—capable 
devices and services, consumers are unlikely to replace their still- 
functional Internet-capable devices simply to add IPv6 support -- 
they don’t know or don’t care about IPv6; they simply want their 
devices to work as advertised. 


This lack of support is making the eventual IPv6 transition 
considerably more difficult, and drives the need for expensive and 
complicated transition technologies to extend the life of IPv4-only 
devices as well as to eventually interwork IPv4-only and IPv6-only 
hosts. While IPv4 is expected to coexist on the Internet with IPv6 
for many years, a transition from IPv4 as the dominant Internet 
Protocol version towards IPv6 as the dominant Internet Protocol 
version will need to occur. The sooner the majority of devices 
support IPv6, the less protracted this transition period will be. 


2. Clarifications and Recommendation 


To ensure interoperability and proper function after IPv4 exhaustion, 
support for IPv6 is virtually a requirement. Rather than update the 
existing IPv4 protocol specification standards to include IPv6, the 
IETF has defined a completely separate set of standalone documents 
that cover IPv6. Therefore, implementers are cautioned that a 
distinction must be made between IPv4 and IPv6 in some IETF documents 
where the term "IP" is used generically. Current requirements for 
IPv6 support can be found in [RFC6204] and [RFC6434]. Each of these 
documents contains specific information, requirements, and references 
to other Draft and Proposed Standards governing many aspects of IPv6 
implementation. 
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Many of the IETF’s early documents use the generic term "IP" 
synonymously with the more specific "IPv4". Some examples of this 
potential confusion can be found in [RFC1812], especially in 
Sections 1, 2, and 4. Since RFC 1812 is an IPv4 router 
specification, the generic use of IP in this standard may cause 
confusion as the term "IP" can now be interpreted to mean 

IPv4 + IPv6, IPv6-only, or IPv4-only. Additionally, [RFC1122] is no 
longer a complete definition of "IP" or the Internet Protocol suite 
by itself, because it does not include IPv6é. For example, 

Section 3.1 does not contain references to the equivalent standards 
for IPv6 for the Internet layer, Section 3.2 is a protocol 
walk-through for IPv4 only, and Section 3.2.1.1 explicitly requires 
that an IP datagram whose version number is not 4 be discarded, which 
would be detrimental to IPv6 forwarding. Additional instances of 
this type of problem exist that are not discussed here. Since 
existing RFCs say "IP" in places where they may mean IPv4, 
implementers are cautioned to ensure that they know whether a given 
standard is inclusive or exclusive of IPv6. To ensure 
interoperability, implementers building IP nodes will need to support 
both IPv4 and IPv6. If the standard does not include an integral 
definition of both IPv4 and IPv6, implementers need to use the other 
informative references in this document as companion guidelines for 
proper IPv6 implementations. 


To ensure interoperability and flexibility, the best practices are as 
follows: 


o New IP implementations must support IPv6. 
o Updates to current IP implementations should support IPv6. 


o IPv6 support must be equivalent or better in quality and 
functionality when compared to IPv4 support in a new or updated IP 
implementation. 


o New and updated IP networking implementations should support IPv4 
and IPv6 coexistence (dual-stack), but must not require IPv4 for 
proper and complete function. 


o Implementers are encouraged to update existing hardware and 
software to enable IPv6 wherever technically feasible. 
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4. Security Considerations 


There are no direct security considerations generated by this 


document, 


but existing documented security considerations for 


implementing IPv6 will apply. 
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